NETWORK DEVICE MIMIC SUPPORT 

BACKGROUND OF THE INVENTION 



Field of the Invention 

The invention concerns the mimicking of 
legacy network devices to extend the functional 
capabilities of the legacy network devices. 
Specifically, the invention is used to represent one 
or more legacy network devices by isolating the 
legacy network devices from the external network and 
by transparently acting on behalf of the legacy 
network devices for function requests which they do 
not inherently support. 

Description of the Related Art 

Large network environments , such as a 
network for supporting a business office 
environment, often contain many network devices, 
such as network printers, of different types and 
generations having different functional 
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capabilities * As new technologies emerge and 
improved functionality is implemented in new models 
or generations of network devices, the functions 
available within a network can vary greatly 
5 depending on which network device is being utilized 

For example, some newer printers in the network 
environment may support secure printing while the 
older printers in the network environment do not 
support secure printing. 

10 It is generally desirable to implement new 

technologies and improvements across an entire 
network environment, thereby making the same set of 
functional capabilities available to all network 
users for all network devices. Otherwise, some 

15 network users may be excluded from taking advantage 

of new beneficial capabilities, such as secure 
printing and e-mail printing, if their assigned 
network device does not support the new 
functionality supported by other newer network 

20 devices. 

One solution to this problem is to simply 
replace all legacy network devices with new network 
devices having the desired new functional 
capabilities • The effort and expense involved in 

2 5 undertaking this solution is great, and is 

impracticable when new enterprise applications 
requiring new functional capabilities are 
implemented on a frequent basis. 

Alternatively, another solution to this 

3 0 problem is to modify the legacy network devices by 

downloading new firmware to each legacy network 
device. However, this solution also requires 
significant effort by a network administrator or 
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service person to physically access each legacy 
network device and then download an appropriate 
version of firmware to make the legacy device 
support functionality consistent with other network 
5 devices. In many cases, it is not possible to 

download a new version of firmware to the legacy 
device for implementation of a new function because 
of hardware and design limitations of the legacy 
device . 

10 Yet another solution to the problem is to 

place a support device on the network near each 
legacy network device for supporting the desired 
additional functionality for the corresponding 
legacy network device. This solution has the 

15 drawback of not being transparent to users of the 

legacy network devices, thereby requiring network 
users to be aware of the IP address for the support 
device corresponding to a given legacy network 
device in order to utilize the additional 

2 0 functionality provided by the support device. 



SUMMARY OF THE INVENTION 
The present invention addresses the 
foregoing problems by mimicking legacy network 

25 devices, such as printers, to provide additional 

functional capabilities for the legacy network 
devices. In particular, the invention discovers 
legacy network devices on a local network and 
responds to network messages on an external network 

3 0 which are directed to the legacy network devices. 

The term "legacy network devices" as used herein 
includes both older network devices and newer 
network devices which lack the ability to support a 
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desired enterprise functionality, such as e-mail 
printing. Accordingly, the invention performs 
additional functions on behalf of the legacy network 
devices in a manner which is transparent to client 
5 devices on the external network. The presence of 

the e-mail mimic device can also be made transparent 
to the legacy network devices on the local network. 

Accordingly, one aspect of the invention 
concerns the mimicking of network devices in a 

10 computing device having first and second network 

interface cards, the first network interface card 
connecting the computing device to an external 
network and the second network interface card 
connecting the computing device to a local network. 

15 The invention includes receiving an incoming message 

from a client network device residing on the 
external network, the incoming message being 
directed to a legacy network device residing on the 
local network, and determining if the incoming 

2 0 message requires a function provided by an 

application module residing in the computing device. 
In the case that the incoming message requires a 
function provided by the application module, the 
incoming message is redirected to the application 
25 module which performs the required function in 

response to the incoming message. In the case that 
the incoming message does not require a function 
provided by the application module, the incoming 
message is passed through the local network to the 

3 0 legacy network device residing on the local network. 

Preferably, the application module sends 
local messages over the local network to communicate 
with a corresponding legacy network device, and each 
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such local message uses a preset IP address of the 
second network card as the source IP address. If 
desired, the local message from the application 
module can use the IP address of the client network 
5 device as the source IP address in the message. The 

application module also sends messages to the client 
network device and uses the IP address of the 
corresponding legacy network device as the source IP 
address in the message to the client network device. 

10 In addition, all legacy network devices on the local 

network are discovered by listening to traffic on 
the local network and then sending discovery 
requests to the detected legacy network devices to 
obtain information related to the devices . The 

15 mimic device then periodically polls the discovered 

legacy network devices to determine their current 
status . A set of rules is used in the determining 
step to determine if an incoming message should be 
redirected to the application module or passed over 

2 0 the local network to the corresponding legacy 

network device. Rules are created based on the 
discovery information for each legacy network 
device. Rules are also dynamically created based on 
ports that are initiated by both the application 
25 module and the legacy network devices. Preferably, 

the invention also prevents the legacy network 
devices and the application module from using the 
same port identifiers. 

By virtue of the foregoing, the invention 

3 0 provides an efficient way to extend the functional 

capabilities of legacy network devices in a manner 
which is transparent to other devices on the 
external network. Accordingly, the cost and time 
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associated with purchasing new network devices or 
upgrading firmware in all legacy network devices in 
the network environment is avoided* The network 
administrator does not have to publish the existence 
5 of the mimic device to all other network users 

because the mimic device is transparent by acting on 
behalf of legacy network devices for functionality 
which the legacy network devices would not otherwise 
support. 

10 In another aspect of the invention, the 

invention concerns mimicking network devices through 
a computing device having first and second network 
interface cards, the first network interface card 
connecting the computing device to an external 

15 network and the second network interface card 

connecting the computing device to a local network. 
The invention includes discovering a plurality of 
legacy network printers on the local network by 
detecting messages on the local network from each of 

2 0 the plurality of legacy network printers, and 

creating a rule in a rules table for each of the 
discovered legacy network printers, each rule 
containing the IP address of the corresponding 
legacy network printer and indicating whether an 
25 application module in the computing device performs 

a function on behalf of the corresponding legacy 
network printer. The invention further includes 
receiving an incoming message from a client network 

i 

device residing on the external network, the 

3 0 incoming message being directed to an IP address of 

a designated one of the plurality of legacy network 
printers, and determining, based on the rule 
corresponding to the designated legacy network 
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printer, if the incoming message requires a function 
performed by the application module. In the case 
that the incoming message requires support from the 
application module, the incoming message is 
5 redirected to the application module which performs 

the required function in response to the incoming 
message. In the case that the incoming message does 
not require a function provided by the application 
module, the incoming message is passed through the 
10 local network to the designated legacy network 

printer . 

Preferably, the application module sends 
local messages over the local network to communicate 
with the corresponding legacy network printer, and 
15 each such local message uses a preset IP address of 

the second network card as the source IP address. 
If desired, the local message from the application 
module to the legacy network printer can use the IP 
address of the client network device as the source 

2 0 IP address in the message. The application module 

also sends messages to the client network device and 
uses the IP address of the corresponding legacy 
network printer as the source IP address in the 
message to the client network device. In addition, 
25 the discovery of each legacy network printer 

includes sending a discovery request to each 
detected legacy network printer to obtain 
information related to the printer. Rules are also 
dynamically created based on ports that are 

3 0 initiated by both the application module and the 

legacy network printers. Preferably, the invention 
prevents the legacy network printers and the 
application module from using the same port 
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identifiers* It should be noted that the mimic 
device can use one or more discriminators in 
addition to the IP address in a message to determine 
whether the mimic device should capture and respond 
5 to the message on behalf of one of the legacy 

network devices. 

By virtue of the foregoing, the invention 
provides an efficient way to extend the functional 
capabilities of legacy network printers in a manner 

10 which is transparent to other devices on the 

external network. Accordingly, the cost and time 
associated with purchasing new network printers or 
upgrading firmware in all legacy network printers in 
the network environment is avoided. The network 

15 administrator does not have to publish the existence 

of the mimic device to all other network users 
because the mimic device is transparent by acting on 
behalf of legacy network printers for functionality 
which the legacy network printers would not 

2 0 otherwise support. 

This brief summary has been provided so 
that the nature of the invention may be understood 
quickly. A more complete understanding of the 
invention can be obtained by reference to the 
25 following detailed description of the preferred 

embodiment thereof in connection with the attached 
drawings . 

BRIEF DESCRIPTION OF THE DRAWINGS 

3 0 Figure 1 is a depiction of a network 

environment in which the present invention may be 
practiced. 
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Figure 2A is a block diagram illustrating 
an internal architecture of a mimic device according 
to one embodiment of the present invention. 

5 Figure 2B is a block diagram illustrating 

the modules contained in the fixed disk of the mimic 
device depicted in Figure 2A according to one 
embodiment of the present invention. 

Figure 3 is a block diagram depicting the 
10 functional components of a mimic device according to 

one embodiment of the present invention. 

Figure 4 is a table diagram depicting a 
target descriptor table according to one embodiment 
of the present invention. 
15 Figure 5 is a flowchart for explaining a 

discovery process according to one embodiment of the 
present invention . 

Figure 6 is a flowchart for explaining a 
periodic polling discovery process according to one 

2 0 embodiment of the present invention. 

Figure 7 is a block diagram depicting rules 
tables according to one embodiment of the present 
invention. 

Figure 8A is a block diagram depicting an 
25 IN rules table according to one embodiment of the 

present invention . 

Figure 8B is a block diagram depicting an 
OUT rules table according to one embodiment of the 
present invention . 

3 0 Figure 9 is a flowchart for explaining the 

application of a frame to the IN and OUT rules 
tables depicted in Figures 8A and 8B according to 
one embodiment of the present invention. 
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Figure 10 is a flowchart for explaining the 
processing of frames according to one embodiment of 
the present invention. 

Figure 11 is a block diagram depicting a 
5 routing table according to one embodiment of the 

present invention ♦ 

Figure 12 is a flowchart for explaining 
dynamic port registration according to one 
embodiment of the present invention. 
10 Figure 13 is a flowchart for explaining the 

mapping of port identifiers according to one 
embodiment of the present invention. 

Figure 14 is a flowchart for explaining the 
routing of an incoming frame according to one 
15 embodiment of the present invention. 

Figure 15 is a flowchart for explaining the 
routing of an outgoing frame according to one 
embodiment of the present invention. 

2 0 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The invention is directed to a mimic device 
for use in a general network environment in order to 
augment the functionality of existing network 
devices. In particular , the mimic device of the 
25 present invention utilizes two separate network 

interface cards in order to allow the mimic device 
to act as a middle man between the general network 
which is connected to one of the network interface 
cards in the mimic device, and a local network which 

3 0 is connected to the second of the network interface 

cards in the mimic device. In this manner, a number 
of existing legacy network devices, such as network 
printers, can be isolated on the local network 
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behind the mimic device from the general , external 
network. The mimic device can then initially pass 
through all network traffic from the external 
network from the first network interface card to the 
5 legacy network devices on the local network via the 

second network interface card. The mimic device 
listens to the local network and discovers all of 
the legacy network devices thereon, after which the 
mimic device can utilize applications within the 

10 mimic device to augment the functional capabilities 

of each discovered legacy network device. 

The applications are provided in the mimic 
device to augment the legacy network devices in 
order to add functional capabilities on their 

15 behalf. For example, if a network printer on the 

local network behind the mimic device does not have 
e-mail printing capability, the mimic device can 
contain an e-mail printing application, whereupon 
the mimic device intercepts requests from a client 

2 0 on the external network for e-mail printing from a 

network printer on the local network and then 
performs the e-mail printing function on behalf of 
the network printer by sending a rendered print job 
to the network printer in response to the request 

2 5 from the client. In this example, the mimic device 

responds to the client on the external network using 
the IP address of the network printer so that the 
presence of the mimic device is transparent to the 
client. In addition, the mimic device can support a 

3 0 connection to a client on the external network which 

is initiated by a legacy network device on the local 
network. For example, a legacy network device my 
send a network time protocol (NTP) request which is 
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directed to an NTP server on the external network. 
The mimic device could intercept the NTP request and 
then send its own NTP request to the NTP server on 
behalf of the legacy network device. The mimic 
5 device would then receive a response from the NTP 

server, such as the current time, and then forward 
the response to the legacy network device, using 
either the IP address of the mimic device or the IP 
address of the NTP server as the source IP address. 

10 Accordingly, the mimic device provides an efficient 

and inexpensive way to augment functional 
capabilities of legacy network devices in a manner 
which is transparent to network users on the 
external network . 

15 Figure 1 depicts a network environment in 

which the present invention may be practiced. As 
seen in Figure 1, external network 10 is a typical 
network which is preferably supported by TCP/IP and 
other common network protocols which are discussed 

2 0 further herein. Connected to external network 10 

are server 11, which is a typical network server, 
and workstation 12. Workstation 12 is a typical 
computing workstation having a host processor with a 
CPU, fixed disk and RAM, and a display, keyboard and 

2 5 mouse for interacting with the host processor. 

Server 11 is a typical server having a host 
processor which includes a CPU, RAM, ROM and a large 
fixed disk for containing files and/or applications 
which can be accessed and shared by users on 

3 0 external network 10. 

As seen in Figure 1, mimic device 2 0 has 
external network interface card 22 and local network 
interface card 21. As mentioned above, this allows 
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mimic device 2 0 to act as a controlled bridge 
between external network 10 and local network 14. 
External network interface card 22 connects mimic 
device 20 to external network 10 and local network 
5 interface card 21 connects mimic device 2 0 to local 

network 14. A plurality of network devices can be 
residing on local network 14 for communication with 
mimic device 20. In the example shown in Figure 1, 
legacy network printers 15 and 16 are provided on 

10 local network 14 and are therefore in connection 

with mimic device 20 via local network interface 
card 21. In addition, it can be appreciated that 
the mimic device can also be used as a bridge to 
connect non-internet capable network devices to 

15 external network 10. For example, local network 14 

could be a USB network, and legacy network printers 
15 and 16 could be non-network capable printers. 
Accordingly, mimic device 2 0 would act as a bridge 
between printers 15 and 16 via the USB connection of 

2 0 local network 14 to external network 10. 

Each of legacy network printers 15 and 16 
has a network interface card (not shown) for 
connection to local network 14. Legacy network 
printers 15 and 16 may be typical network printers, 

2 5 such as laser jet printers or ink jet printers, and 

have certain limited functional capabilities to 
support network printing applications. For purposes 
of explaining the present invention, legacy network 
printers 15 and 16 are assumed to lack certain 

3 0 enterprise printing functional capabilities, such as 

secure printing, e-mail printing, or some other 
printer functionality. For this reason, legacy 
network printers 15 and 16 are isolated from 
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external network 10 by being placed on local network 
14 such that mimic device 2 0 can provide additional 
enterprise printing functional capabilities on 
behalf of legacy network printers 15 and 16. It 
5 should be appreciated that mimic device 20 can be 

utilized to augment functional capabilities of any 
network device on local network 14 and is not 
limited to use with network printers only. 

Figure 2A is a block diagram for explaining 

10 the internal architecture of mimic device 20. As 

seen in Figure 2A, mimic device 20 essentially has 
the configuration of a server or other similar 
computing device , with the exception that mimic 
device 2 0 includes two network interface cards. 

15 Mimic device 20 includes system bus 30, CPU 34, RAM 

35, ROM 36, external network interface card 22, 
local network interface card 21 and fixed disk 60. 

Central processing unit (CPU) 34 is a 
programmable microprocessor which is interfaced to 

20 bus 30. Random access memory (RAM) 35 is interfaced 

to bus 3 0 in order to provide CPU 34 with access to 
memory storage, thereby acting as the main run-time 
memory for CPU 34. In particular, when executing 
stored program instruction sequences, CPU 34 loads 

2 5 the instruction sequences from fixed disk 60 (or 

other connected memory media) into RAM 35 and then 
executes those stored program instruction sequences 
out of RAM 35. It should also be recognized that 
standard disk-swapping techniques allow segments of 

3 0 memory to be swapped to and from RAM 35 and fixed 

disk 60. 

Read only memory (ROM) 3 6 stores invariant 
instruction sequences, such as startup instruction 
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sequences for CPU 34 or such as basic input/output 
operating system ("BIOS") sequences for the 
operation of any peripheral devices which may be 
connected to mimic device 2 0 (not shown). External 
5 network interface card 22 and local network 

interface card 21 are two separate and distinct 
network interfaces, thereby allowing mimic device 20 
to connect to external network 10 through external 
network interface card 22 and also to local network 

10 14 through local network interface card 21. As seen 

in Figure 2, both external network interface card 22 
and local network interface card 21 contain similar 
protocol stacks for interfacing external network 10 
and local network 14, respectively, to mimic device 

15 20. It should be noted that the protocol stacks in 

local network interface card 21 and in external 
network interface card 22 do not have to be similar. 
For example, local network 14 could be using a 
protocol different from external network 10, such as 

2 0 a token ring protocol, such that the protocol stack 

in local network interface card 21 would include a 
protocol layer to support the token ring protocol 
environment instead of an IP protocol environment. 

For example, external network interface 

25 card 22 contains network interface layer 41 which is 

a low-level protocol layer to interface directly 
with external network 10. TCP/IP layer 42 is 
provided above network interface layer 41 for 
supporting communication via the TCP/IP protocol 

30 over external network 10. In this manner, mimic 

device 2 0 can send and receive TCP/IP messages, 
often referred to as "frames", over external network 
10. In a similar manner, HTTP layer 43, SNMP layer 
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44, LDAP layer 45 and other layers 46 are provided 
above TCP/IP layer 42 to support communications over 
external network 10 using HTTP, SNMP, LDAP and other 
known networking protocols, respectively. As 
5 mentioned above, the protocol stack shown in local 

network interface card 21 is similar to that of the 
protocol stack discussed above and therefore will 
not be explained in detail. 

Fixed disk 60 is one example of a computer- 

10 readable medium that stores program instruction 

sequences executable by CPU 34 so as to constitute 
operating system 61, external network interface 
driver 62, local network interface driver 63, other 
drivers 68, modules 58, device capability table 73, 

15 routing tables 74, rules tables 75, target 

descriptor table 76, socket library 7 7 and other 
files 79. 

Operating system 61 can be a basic 
operating system such as DOS or UNIX, or can be a 
2 0 common windowing operating system such as Windows 

NT, or another known operating system. External 
network interface driver 62 is utilized to drive 
external network interface card 22 for interfacing 
mimic device 20 to external network 10. In a 

2 5 similar fashion, local network interface driver 63 

is utilized to drive local network interface card 21 
for interfacing mimic device 20 to local network 14. 
Other drivers 68 can be utilized to drive other 
devices which may be connected to mimic device 20 

3 0 (not shown) such as a front panel interface for 

allowing a user to configure and operate mimic 
device 20, or such as a display monitor, key pad and 
mouse (not shown) for achieving the same purpose. 
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Modules 58 are utilized to implement the 
functionality of the present invention and are 
described more fully below. 

Device capability table 73 is utilized to 
5 store information regarding the functional 

capabilities of a range of network devices which may 
be provided on local network 14 and is utilized to 
implement the present invention as discussed further 
below. Routing tables 74 comprises one or more 

10 routing tables which are used to route outgoing 

communications from mimic device 2 0 over external 
network interface card 22 or over local network 
interface card 21 and is described in greater detail 
below. Rules tables 75 is utilized to implement the 

15 functionality of the present invention and is 

described in more detail below. Target descriptor 
table 76 is utilized to contain a plurality of 
target descriptor entries corresponding to the 
legacy network devices discovered by mimic device 20 

2 0 on local network 14 and is discussed further below. 

Socket library 77 is a library used in the present 
invention to track sockets which are opened up by 
applications in the mimic device according to the 
present invention. Lastly, other files 79 contains 
25 other files and/or programs necessary to operate 

mimic device 2 0 and to provide additional 
functionality to mimic device 20. 

Figure 2B is a block diagram showing each 
of the modules in modules 58. Turning to Figure 2B, 

3 0 it can be seen that modules 58 includes network 

device manager (NDM) module 64, network traffic 
controller (NTC) module 65, passive target detector 
(PTD) module 66, dynamic port registrar (DPR) 
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module 67, transport address translator (TAT) 
module 69, secure printing application module 70, 
e-mail printing application module 71, other 
application modules 72 and application manager 
5 module 78 • All of the aforementioned modules are 

specific to implementation of the present invention 
and will be briefly described here with respect to 
Figure 2B, and will be described in more detail 
below with respect to the other figures . 

10 Network device manager module 64 is a low- 

level module utilized to implement the present 
invention for receiving and sending messages, known 
as frames, to and from each of external network 
interface card 22 and local network interface card 

15 21. Network traffic controller module 65 is 

utilized to implement the present invention and 
determines, in conjunction with rules from rules 
tables 75, whether certain messages should be 
handled by mimic device 2 0 on behalf of one of the 

20 legacy network devices on local network 14, or 

should simply be passed through to the corresponding 
legacy network device on local network 14, Passive 
target detector module 66 is utilized to implement 
the present invention and essentially discovers the 

2 5 legacy network devices residing on local network 14 

by obtaining network-related and other functional 
information with respect to each discovered legacy 
network device. Passive target detector (PTD) 
module 66 also performs periodic polling for 

3 0 confirming the status of each discovered legacy 

network device . 

Dynamic port registrar module 6 7 is 
utilized to implement the present invention by 



CA_MAIN 2241 5 V 3 



- 19 - 

monitoring ports opened up by applications within 
mimic device 2 0 and to create rules for redirecting 
messages (frames) to the corresponding applications, 
as needed, so that the applications may act on 
5 behalf of one or more legacy network devices on 

local network 14. Transport address translator 
module 69 is utilized to implement the present 
invention by monitoring sockets opened by the legacy 
network devices on local network 14 and to map the 

10 corresponding socket identifiers to newly-created 

socket identifiers in order to avoid socket 
identifier conflicts with the sockets which are 
opened by applications in mimic device 20. 

Secure printing application module 70 and 

15 e-mail printing application module 71 are examples 

of application modules which can be provided in 
mimic device 2 0 in order to augment the functional 
capability of legacy network printers 15 and 16, or 
other legacy network devices, on local network 14. 

2 0 For example, legacy network printer 15 may have the 

functional capability to support e-mail printing, 
but may not have the functional capability to 
support secure printing. In this regard, mimic 
device 2 0 would utilize secure printing application 
25 module 7 0 to respond to frames received from 

external network 10 which requests secure printing 
services from legacy network printer 15. In a 
similar fashion, if legacy network printer 16 does 
not support e-mail printing, mimic device 2 0 would 

3 0 utilize e-mail printing application module 71 to act 

on behalf of legacy network printer 16 for incoming 
requests from external network 10 for e-mail 
printing services from legacy network printer 16. 
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In this manner , it appears to clients on external 
network 10, such as workstation 12, that each of 
legacy network printers 15 and 16 has the capability 
to support secure printing and e-mail printing when 
5 in fact mimic device 2 0 is providing such additional 

functional capabilities on behalf of the printers in 
a transparent manner. Other application modules 72 
is utilized to support other additional applications 
to augment the functional capabilities of legacy 

10 network devices residing on local network 14. 

Lastly, application manager module 7 8 is utilized by 
the present invention to initiate one or more of the 
aforementioned applications as needed to augment the 
functional capabilities of each legacy network 

15 device. These modules will be discussed in greater 

detail below with respect to the remaining figures. 

Figure 3 is a diagram depicting the 
functional modules of mimic device 20. NDM 64 
manages device drivers utilized by mimic device 2 0 

20 such as external network interface driver 62, local 

network interface driver 63 and drivers associated 
with devices supported by mimic device 2 0 connected 
to local network 14. External network interface 
driver 62 facilitates sending and receiving packets 

25 to and from external network 10. Local network 

interface driver 63 facilitates sending and 
receiving packets to and from local network 14. 
Additionally, NDM 64 maintains routing table 74, 
which is utilized by NDM 64 for routing packets sent 

3 0 by mimic device 20. 

NTC 65 processes frames received by NDM 64 
from either external network 10 or local network 14, 
as well as frames being sent by applications running 
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internally on mimic device 20. NTC 65 processes 
frames by applying a series of rules to each frame. 
The rules are contained in rule tables 75, which are 
managed by NTC 65. PTD 66 detects and monitors 
5 devices on local network 14. PTD 66 maintains 

target descriptor table 76, which contains 
parameters defining the detected devices, such as 
printer 15 and printer 16. Additionally, PTD 66 
notifies other modules within mimic device 20 of any 

10 changes to the detected devices defined in target 

descriptor table 76. 

DPR 67 monitors the opening and closing of 
sockets by applications running on mimic device 20, 
and interacts with NTC 65 to ensure that frames 

15 processed by NTC 65 are channeled correctly. In 

monitoring sockets, DPR 67 refers to socket library 
77, which contains socket descriptors defining the 
sockets opened by applications running on mimic 
device 20. TAT 69 monitors the assignment of port 

2 0 numbers by devices on local network 14, and when 

necessary prevents conflicts between those devices 
and applications running on mimic device 20. 

Application manager module 78 manages the 
applications being run on mimic device 20. Upon 
25 being notified of a new device by PTD 66, 

application manager module 7 8 determines which 
application should be launched to augment the 
capabilities of the newly detected device. Possible 
application modules include secure printing 

3 0 application module 70, which provides secure 

printing services between a host on external network 
10 and a device on local network 14, such as printer 
15 or printer 16. Additionally, e-mail printing 
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applications module 71 provides e-mail printing 
functionality from a host on external network 10 to 
a device on local network 14. Additional 
functionality can be added to mimic device 2 0 by 
5 including other applications to provide needed 

services. Future applications are represented in 
Figure 3 by other printing application module 72. 

The above description of the functional 
modules has been provided in order to briefly 

10 introduce their purposes. A more detailed 

description of the functioning and interactions of 
these modules will be provided below. 

Figure 4 is a depiction of target 
descriptor table 76. Each entry in target 

15 descriptor table 76 is defined by several 

parameters. Target 100 is an identifier 
corresponding to a detected device on local network 
14. Ethernet address 101 provides the ethernet 
address of the detected device. IP address 102 

2 0 provides the IP address of the detected device. IP 

network mask 104 provides the netmask associated 
with the detected device. Default router 105 
provides the address of the default router 
associated with the detected device. SNMP object 
25 identifier 106 provides the SNMP object identifier 

assigned to the detected device. The creation and 
maintenance of these entries are performed by PTD 
66, and will be described in more detail below. 

Figure 5 is a flowchart for describing the 

3 0 discovery process by which mimic device 20 discovers 

each of the legacy network devices , such as legacy 
network printers 15 and 16 on local network 14. 
Turning to Figure 5, it can be seen in step S501 
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that NDM 64 listens through local network interface 
card 21 for network messages on local network 14 
from any of the legacy network devices, such as 
legacy network printers 15 and 16 on local network 
14. Specifically, in an ethernet environment 
supporting TCP/IP, NDM 64 listens for frames from 
any device on local network 14. In this manner, 
when a network printer on local network 14 sends a 
TCP/IP frame containing its source IP address, NDM 
64 captures the frame. It should be recognized that 
NDM 64 is indiscriminate in this function in that it 
simply passes frames to NTC 65 corresponding to all 
network messages which it detects over both external 
network 10 and local network 14. In particular, NDM 
64 interfaces with external network interface driver 
62 and local network interface driver 63 to receive 
frames from external network 10 and local network 
14 , respectively. 

Next, once NDM 64 has detected a frame on 
local network 14, it passes the frame up to NTC 65 
in step S502. Preferably, when PTD 66 is 
initialized, it creates a general capture rule which 
is placed in rules tables 75 for instructing NTC 65 
to capture all frames that are passed to it which 
have been sent over local network 14 from a legacy 
network device having a source IP address within a 
given predetermined range. Accordingly, in step 
S503, NTC 65 examines the frame passed to it from 
NDM 64 to determine if the frame contains a source 
IP address within the IP address range in the broad 
capture rule. If so, NTC 65 captures the frame and 
sends the address pair from the frame, consisting of 
the source IP address and the ethernet address 
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corresponding to local network 14, to PTD 66 (step 
S503) . 

In step S504, PTD 66 examines target 
descriptor table 76 to determine if the address pair 
5 passed to it from NTC 65 contains a source IP 

address which does not yet have a target descriptor 
entry in target descriptor table 76. If no such 
entry exists, PTD 66 identifies the source IP 
address from the address pair as corresponding to a 

10 newly-discovered legacy network printer (step S504). 

In step S505, PTD 66 queries whether it has been 
determined that the source IP address of the address 
pair corresponds to a newly-discovered legacy 
network printer and, if not, flow passes to step 

15 S512. If, however, the source IP address in the 

address pair corresponds to a newly-discovered 
legacy network printer, flow passes to step S506 in 
which PTD 66 sends an SNMP discovery request over 
local network 14 to the newly-discovered legacy 

2 0 network printer corresponding to the source IP 

address from the address pair. It should be noted 
that SNMP is only one example of a protocol for 
supporting the discovery message sent from mimic 
device 20 the legacy network devices on local 
25 network 14. For example, other known protocols 

could be used for the discovery message, such as 
lightweight directory access protocol (LDAP), or a 
proprietary protocol could be used. Preferably, PTD 
66 also prepares at this point a basic target 

3 0 descriptor entry for input into target descriptor 

table 76 wherein the entry contains the source IP 
address and the ethernet address from the address 
pair. 
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As explained above with respect to Figure 
3, the SNMP discovery request sent from PTD 66 is 
passed to NDM 64 which determines from routing table 
74 that the SNMP discovery request message should be 
5 sent through local network interface card 21 and 

over local network 14 to the corresponding newly- 
discovered legacy network printer* 

In step S507 f PTD 66 receives SNMP 
discovery information from the newly-discovered 

10 legacy network printer via NDM 64 and NTC 65. 

Preferably, the SNMP discovery information from the 
newly-discovered legacy network printer includes an 
IP network mask, a default router, and an SNMP 
device ID. The SNMP device ID for the corresponding 

15 newly-discovered legacy network printer allows mimic 

device 20 to determine the make and model and the 
existing functional capabilities of the newly- 
discovered legacy network printer. For this reason, 
device capability table 73 provides a cross- 

2 0 reference between a given SNMP device ID and the 

corresponding make, model, functional information 
and other related information for the network 
printer corresponding to the SNMP device ID. 

In step S508, PTD 66 creates a new target 
25 descriptor entry in target descriptor table 76 based 

on the SNMP discovery information received by PTD 66 
from the newly-discovered legacy network printer. 
As mentioned earlier, PTD 66 has preferably already 
set up a basic target descriptor entry containing 

3 0 the IP address and ethernet address of the newly- 

discovered legacy network printer. PTD 66 fills in 
the remaining fields of the target descriptor entry 
corresponding to the newly-discovered legacy network 



CA_MAIN 22415 V 3 



printer with the received SNMP discovery 
information. In this manner, a target descriptor 
entry now exists in target descriptor table 76 
corresponding to each discovered legacy network 
5 device , such as legacy network printers 15 and 16, 

on local network 14. The target descriptor entry 
contains the address information necessary to reach 
each discovered legacy network device and also 
contains a corresponding SNMP device ID from which 
10 information related to the identity and functional 

capabilities of the legacy network device can be 
derived. 

In step S509, PTD 66 notifies other modules 
in mimic device 2 0 that a new target descriptor 

15 entry has been entered in target descriptor table 

76. Preferably, PTD 66 performs this notification 
by publishing the new target descriptor entry to all 
modules in mimic device 2 0 which have previously 
subscribed with PTD 66 to be notified of such an 

2 0 event. For example, application manager module 7 8 

subscribes to PTD 66 upon initialization of 
application manager module 78 to receive each target 
descriptor entry that is created and entered in 
target descriptor table 76. In this manner, 

2 5 application manager module 78 can be made aware of 

newly-discovered legacy network devices on local 
network 14 in order to initiate the necessary 
applications which are needed to augment the 
functional capabilities of the newly-discovered 

3 0 legacy network device. For example, if PTD 66 

determines that legacy network printer 15 is a 
newly-discovered device, then PTD 66 creates a new 
target descriptor entry after performing the 
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aforementioned SNMP discovery and then notifies 
application manager module 7 8 of the new target 
descriptor entry corresponding to legacy network 
printer 15. In this example, application manager 
5 module 78 then initiates the applications which are 

necessary to augment the functional capabilities of 
legacy network printer 15 which are determined from 
device capability table 73 . If legacy network 
printer 15 does not inherently support e-mail 

10 printing capabilities, application manager module 7 8 

instructs e-mail printing application module 71 to 
perform this service on behalf of legacy network 
printer 15 (step S510). Preferably, each 
application in mimic device 20 which acts on behalf 

15 of a given legacy network device opens a socket for 

receiving frames on behalf of that device. The 
details of this aspect of the invention are 
discussed further below with reference to other 
figures . 

2 0 Next, in step S511, NDM 64 creates a new 

entry in routing table 74 based on the address pair 
comprised of the IP address and ethernet address of 
the newly-discovered legacy network printer. In 
this manner, when NDM 64 subsequently receives an 
25 outgoing frame containing a destination address 

corresponding to the IP address of the discovered 
legacy network printer, NDM 64 will determine based 
on routing table 7 4 that the frame should be sent 
through local network interface card 21 over local 

3 0 network 14 to the discovered legacy network printer 

corresponding to the IP address. In step S512, PTD 
66 sends a periodic poll discovery message to each 
legacy network printer which has been discovered and 
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has a target descriptor entry in target descriptor 
table 76 in order to verify the current status of 
each discovered legacy network printer. The details 
of this step are discussed further with respect to 
5 Figure 6. Flow then passes to return in step S513. 

Figure 6 is a flowchart for explaining the 
periodic polling discovery which is performed in 
step S512 of the flowchart of Figure 5. First, in 
step S512, PTD 66 sends a periodic SNMP discovery 

10 request to each legacy network device, such as 

legacy network printers 15 and 16, which have target 
descriptor entries in target descriptor table 76. 
The SNMP discovery request is the same as that 
discussed above with regard to the initial discovery 

15 of each legacy network device on local network 14. 

Next, in step S601, PTD 6 6 receives SNMP discovery 
information from each legacy network device, such as 
legacy network printers 15 and 16, which respond to 
the periodic discovery request (step S601). In step 

20 S602, PTD 66 determines whether there has been a 

non-response for any of the legacy network devices 
which have been sent a periodic SNMP discovery 
request. If there has been a non-response, the 
target descriptor entry corresponding to the legacy 

25 network device which did not respond is removed from 

target descriptor table 76 (step S603). Preferably, 
PTD 6 6 sets an expiration timer corresponding to 
each target descriptor entry in target descriptor 
table 7 6 when the corresponding target descriptor 

3 0 entry is created or verified as the result of 

periodic discovery polling. 

If a non-response occurs, PTD 66 simply 
does not update the expiration timer corresponding 
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to the target descriptor entry for the non- 
responding legacy network device. A service then 
preferably periodically cleans out target descriptor 
table 7 6 of all target descriptor entries having 
5 expired expiration timers. In this manner, the 

appropriate target descriptor entries in target 
descriptor table 76 are removed when their 
corresponding legacy network devices fail to respond 
to periodic discovery polling. Next, in step S604, 

10 the SNMP discovery information received from each 

responding legacy network device in response to the 
periodic discovery request is compared to the data 
in each corresponding target descriptor entry in 
target descriptor table 76. In step S605, it is 

15 determined for each responding legacy network device 

whether the data in the corresponding target 
descriptor entry has changed based on the received 
SNMP discovery information in response to the 
periodic SNMP discovery request. If the information 

2 0 has changed, flow passes to step S606 in which the 

target descriptor entry for the corresponding legacy 
network device is modified with the new information 
received in the SNMP discovery information from the 
legacy network device in response to the periodic 
25 SNMP discovery request. In step S607, PTD 66 

notifies other modules in mimic device 2 0 of each 
modified and deleted target descriptor entry. This 
notification is performed as discussed above whereby 
the aforementioned changed target descriptor entries 

3 0 are published to each module in mimic device 2 0 

which has previously subscribed with PTD 6 6 to 
receive such notification. Flow then passes to 
return in step S608. 
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Figure 7 is a diagram depicting rule tables 
75. Rule Tables 75 contains several tables of rules 
utilized by NTC 65 in processing frames received and 
sent by mimic device 20. In this embodiment four 
5 rule tables are defined in rule tables 75 , however 

additional rule tables may exist in other 
embodiments. IN table 110 contains rules that are 
applied to frames by NTC 65 when they are received 
by mimic device 20. OUT table 111 contains rules 

10 that are applied by NTC 65 to frames prior to 

sending them to NDM 64 to be sent out of mimic 
device 20. MAP LOCAL table 112 is a sub- table 
contained within IN table 110, and is utilized by 
TAT 69 for managing port assignments. MAP EXTERNAL 

15 table 114 is a sub-table contained within OUT table 

111, and is also utilized by TAT 69 for managing 
port assignments . 

Figure 8 A depicts IN table 110 together 
with three sample table entries. Each entry defines 

2 0 a rule based on several parameters to be used by NTC 

65 in processing frames. The parameter table 120 
identifies the table the rule is found on. Possible 
tables include IN table 110 and OUT table 111, as 
well as any subtables such as MAP LOCAL table 112. 
25 Parameter timeout 121 can provide a time duration, 

the expiration of which causes the rule to be 
removed from the table. In the alternative, 
parameter timeout 121 could be set as STATIC, which 
provides for the particular rule to remain on the 

3 0 table until a functional module requests its 

removal . 

Each rule is also defined by a set of 
discriminators (source IP 122, destination IP 124, 



CA_MAIN 22415v 3 



source port 125 and destination port 126) and an 
action 128. NTC 65 compares frames against the 
discriminators, and if a match occurs the designated 
action 12 8 is executed. In this embodiment four 
5 discriminators are defined: source IP 122, 

destination IP 124, source port 125 and destination 
port 126. Source IP 122 and source port 125 may 
contain the IP address and port number of the source 
of a frame. Destination IP 124 and destination port 

10 12 6 may contain the IP address and port number of 

the destination for a frame. The entries for the 
discriminators may be either a specific value or 
address (IP address or port number), a wildcard that 
matches with all possible values (an asterisk), or a 

15 macro which matches with a specific range of 

possible values ([LOCAL], for example, will find a 
match with any address detected on local network 
14). While this embodiment utilizes four 
discriminators, additional discriminators such as 

2 0 protocol and source interface of the frame may also 

be used. 

Upon finding a match between a frame and 
the discriminators of a rule, the designated action 
128 is executed. For example, CAPTURE will cause 

2 5 the frame to be captured and submitted for further 

processing by one of the functional modules, such as 
PTD 66. BRANCH will cause the frame to be processed 
using a subtable indicated in the BRANCH action. 
REDIRECT causes the frame to be sent to one of the 

30 application modules within mimic device 20. ACCEPT 

causes the frame to be passed through mimic device 
20 without further processing by mimic device 20. 
Additional actions may be defined and utilized 
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within mimic device 2 0 for processing received 
frames • 

Figure 8B depicts OUT table 111, which is 
set up in the same manner as IN table 110. The 
5 parameters defining each rule entry are the same as 

described above with respect to Figure 8A, and are 
therefore identified with the same designating 
numbers. Since OUT table 111 is structured in the 
same manner as IN table 110, a detailed explanation 

10 of the structure will be omitted. 

Figure 9 is a flowchart briefly summarizing 
the processing performed by NTC 65 on frames 
received by mimic device 20. In step S901, a frame 
is received by one of the network interfaces such as 

15 external network interface 32 or local network 

interface 31. Upon receiving the message, NDM 64 
notifies NTC 65 that the frame is ready for 
processing. In step S904, the received frame is 
processed by NTC 65 using the rules contained within 

20 IN table 110. If the frame is not dropped or 

redirected by NTC 65 in applying IN table 110, in 
step S9 05 processing of the frame by NTC 65 is 
shifted and performed in step S906 using the rules 
contained in OUT table 111. Otherwise, in step S905 

25 processing by NTC 65 is stopped and NTC 65 awaits 

the next frame in step S908. In step S902, a frame 
is received by NTC 65 from an application module, 
such as secure printing application module 70. NTC 
65 then proceeds to process the frame using the 

30 rules contained within OUT table 111 in step S906. 

Upon completion of step S906, NTC 65 again waits for 
the next frame in step S908. 
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The description of Figure 9 above briefly 
described NTC 65 applying a rule table, such as IN 
table 110, in processing a frame. Figure 10 is a 
flowchart depicting in more detail the process of 
5 processing a received frame using rules contained 

within a particular rule table • In step S1001, NTC 
65 initiates processing of the received frame. 
Typically, initiation occurs when NTC 65 reaches a 
point in the general processing, such as that 

10 depicted in Figure 9, where a received frame is to 

be processed using a particular rule table. In step 
S1002, NTC 65 determines whether the frame matches 
the discriminators contained within the first rule 
of the rule table. If these discriminators do not 

15 match the frame, in step S1004 it is determined 

whether NTC 65 is done processing using the rule 
table. If processing is not done, in step S1005 NTC 
65 continues to the next rule in the rule table and 
returns to step SI 002 to determine if the frame 

2 0 matches the discriminators of that rule. However, 

if NTC 65 is done processing using the rule table, 
processing is returned to the general processing 
depicted in Figure 9 in step S1010. 

If NTC 65 determines in step S1002 that the 

2 5 frame does match the discriminators defined in the 

rule, the action associated with that rule is 
executed in step S1006. After the action associated 
with that rule has been executed in step SI 006, it 
is determined in step S1008 whether the processing 

3 0 using the rule table is done. If processing using 

the rule table is not done, NTC 65 proceeds to the 
next rule in the rule table in step S1009 and 
returns to step S1002 to compare the discriminators 
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of that rule with the frame. If processing is 
complete using the rule table , NTC 65 again returns 
to general processing in step S1010. Whenever NTC 
65 is called upon to process a frame using a 
5 particular rule table , NTC 65 traverses the relevant 

rule table as described above. 

Figure 11 depicts routing Table 74 utilized 
by NDM 64 in determining which network interface to 
transmit frames. Each entry in routing Table 74 is 

10 defined using several parameters such as destination 

140 , netmask 141, gateway 142, device 144 and notes 
145, which describe the particular entry in the 
table. The detailed definition and functioning of 
each of the parameters are well known to those 

15 skilled in the art, and therefore are not provided 

in this description . 

Figure 12 is a flowchart depicting the 
processing performed by DPR 67. In step S12 01, DPR 
67 initializes and waits for application modules in 

2 0 mimic device 20 to begin working with sockets. In 

step S1202 an application such as e-mail printing 
application module 71, begins executing and creates 
a socket for communication over the network. When 
an application opens a socket for communication over 
25 the network, a function is called to open the 

socket. When one of these functions are called, DPR 
67 is notified in step S1204 of the socket creation. 

When an application opens a socket for 
communication, an entry is made in socket library 77 

3 0 containing a socket descriptor for defining the 

socket opened by the application. In step S1205, 
DPR 67 reads the socket descriptor from socket 
library 77 to determine the parameters of the new 
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socket. In step S1208, DPR 67 constructs a redirect 
rule in NTC 65 based on the socket descriptor 
corresponding to the new socket. Utilizing this 
redirect rule, NTC 65 redirects frames received by 
mimic device 20 to the application running on the 
mimic device 20 rather than passing the frame 
through to a device on local network 14. 

In step S1209, DPR 67 waits for the socket 
to be closed. DPR 67 may wait for a function to be 
called which closes the socket, or in the 
alternative DPR 67 may wait a specified period of 
time beginning when the socket is opened. Once the 
socket has been closed, in step S1210 DPR 67 removes 
the redirect rule from NTC 65 corresponding to the 
closed socket. In the manner described above, DPR 
67 can ensure that any traffic received from 
external network 10 is directed to application 
modules running on mimic device 20 in the case where 
mimic device 20 is augmenting the capabilities of a 
device on local network 14. 

Figure 13 depicts the processing performed 
by TAT 69. In step S1301, TAT 69 initializes and 
prepares for processing. In step S1302, TAT 69 
constructs branch and capture rules in NTC 65. TAT 
69 constructs a branch rule in IN table 110 for 
directing specific received frames to map local 
table 112. In addition, TAT 69 constructs a branch 
rule in OUT table 111 for directing specific frames 
to map external table 114. Additionally, TAT 69 
constructs a capture rule within the map local table 
112 to capture specific frames. The capture rule 
constructed in map local table 112 captures all 



frames received from devices on local network 14 
using a dynamic port address. 

In step S1304, NTC 65 receives a frame for 
processing from NDM 64. In step S1305, it is 
determined whether the received frame is from the 
local network and whether it contains a dynamic port 
address. If it is from the local network and 
contains a dynamic port address, the branch rule 
created by TAT 69 branches the frame processing to 
map local table 112 in step S1308. If the received 
frame is not from the local network and/or does not 
contain a dynamic port address, NTC 65 proceeds with 
normal frame processing in step S1306 and TAT 69 
returns to a wait state in step S1314. 

As indicated above, NTC 65 branches to map 
local table 112 in step S1308 when it is determined 
that the received frame is from a local network with 
a dynamic port address. In step S1309, NTC 65 
traverses map local table 112 and determines whether 
the frame matches the discriminators of an existing 
map rule within that table (as well as determining 
if there is a match with any other rules contained 
within map local table 112, and executing the rule 
action for those rules that do match). If there is 
a match of the discriminators, in step S1310 the map 
rule is executed and TAT 69 returns to a wait state 
for the next frame in step S1314. If there is no 
existing map rule corresponding to the 
discriminators of the frame, in step S1311 TAT 69 
allocates a new dynamic address for that frame. 

In assigning the new dynamic address to the 
frame, TAT 69 may utilize its own internal list of 
unused port numbers. In the alternative, TAT 69 may 
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create a dummy socket and receive a new port number 
allocated by the network stack of mimic device 2 0 
and utilize that new dynamic address for the frame 
being processed. In step S1312, TAT 69 constructs 
5 map rules corresponding to the newly assigned 

dynamic address. In map local table 112, TAT 69 
constructs a map rule which maps the existing port 
address of a frame to the newly allocated port 
address when a frame is processed containing the 

10 original port number. In the map external table 

114 , TAT 69 constructs a map rule for mapping the 
newly allocated dynamic address back to the original 
dynamic port address upon receiving a frame from the 
external network containing to the new dynamic 

15 address. Upon completion of constructing the map 

rules, the newly created map rule is executed on the 
present frame being processed in step S1310, and TAT 
69 returns to a wait state for the next frame in 
step S1314. 

2 0 Preferably, the rules contained within map 

local table 112 and map external table 114, which 
are utilized by NTC 65, do not contain terminal 
actions. Accordingly, TAT 69 processes the frames 
and then returns processing to NTC 65, thereby 

2 5 transparently performing address translation on 

frames utilizing dynamic port addresses without 
interfering with the general processing performed by 
NTC 65. It should be noted that other sub-tables 
can be created by any application that requires 

30 them. These sub-tables, unlike the sub-tables used 

by TAT 69, may include terminal actions. 

Figure 14 is a flowchart depicting the 
process mimic device 20 undertakes upon receiving a 
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frame from external network 10. In step S1401, NDM 
64 receives a frame from external network 10 and 
notifies NTC 65 that a frame is available for 
processing. Upon receiving notification of a 
5 received frame, NTC 65 begins processing the frame 

in step S1402 by applying the frame to the rule 
tables within rule tables 75 as described using 
Figure 9. In applying the frame to rule tables 75 , 
the frame may be passed through or redirected in 

10 step S1404 depending on the which rules are applied 

to the frame by NTC 65 during processing. If the 
frame is not redirected, NTC 65 passes the frame 
back to NDM 64 in step S1405 and NDM 64 passes the 
frame on to the device on the local network as 

15 indicated in the frame via the local network 

interface 31 in step S1406. After the frame is 
passed through by NDM 64, processing is returned to 
a wait state in step S1410. 

On the other hand, if the rules applied by 

2 0 NTC 65 redirect the frame in step S1404, NTC 65 

forwards the frame to the appropriate application 
module running on mimic device 20 as dictated by the 
rule action. In step S1409, the application module 
on mimic device 20 that receives the frame processes 
25 the frame. Once processing by the application 

module is complete, processing is returned to a wait 
state in step S1410. 

Figure 15 is a flowchart for explaining how 
an application in mimic device 20 communicates with 

3 0 a device on either external network 10 or local 

network 14. For example, if e-mail printing 
application module 71 is supporting an e-mail 
printing function on behalf of legacy network 
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printer 15 , then e-mail printing application module 
71 may need to communicate with the requesting 
client on external network 10, such as workstation 
12 , and may also need to communicate with legacy 
network printer 15 on local network 14 in order to 
spool the print job to legacy network printer 15. 
Accordingly, network messages prepared by e-mail 
printing application module 71 need to be addressed 
appropriately to the desired device on the 
appropriate network, and the source IP address in 
the outgoing message must also be set to achieve the 
desired effect of transparency. The example set 
forth in the flowchart of Figure 15 is for an 
outgoing message from secure printing application 
module 70. 

In step S1501, secure printing application 
module 70 prepares an outgoing message which may be 
an acknowledgment message to the requesting client 
device on external network 10 such as workstation 
12, or may be a print spool message to legacy 
network printer 15. In step S1502, secure printing 
application module 70 sends the outgoing message to 
NTC 65. NTC 65 then applies the outgoing message to 
the out rule table of rules tables 75 in order to 
determine how the outgoing message should be 
addressed (step S1503). In step S1504, it is 
determined based on the out rule table whether the 
outgoing message is directed to the requesting 
client network device. If so, flow passes to step 
S1505 in which the IP address of the corresponding 
legacy network printer which secure printing 
application module 70 is acting on behalf of is used 
as the source IP address in the outgoing message. 
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In this manner, the existence of mimic device 2 0 
will be made transparent to the requesting client 
network device because the source IP address in the 
acknowledgment message received by the requesting 
5 client network device contains the source IP address 

of the legacy network printer which is performing 
the requested printing function. Next, after step 
S1505, the outgoing message is sent to NDM 64 which 
utilizes routing table 74 to determine that the 

10 outgoing message must be sent through external 

network interface card 22 over external network 10 
to the requesting client network device, such as 
workstation 12 (step S1506). Flow then passes to 
return in step S1515. 

15 If it is determined in step S1504 that the 

outgoing message from secure printing application 
module 7 0 is not directed to the requesting client 
network device, then flow passes to step S1507 in 
which it is determined whether the outgoing message 

2 0 is directed to the legacy network device, such as 

legacy network printer 15, which secure printing 
application module 70 is acting on behalf of. If it 
is determined in step S1507 that the outgoing 
message is directed to the corresponding legacy 
25 network device, then flow passes to step S1508 in 

which it is determined whether the outgoing message 
needs to be transparent to the legacy network 
device. In other words, it is determined whether 
the source IP address in the outgoing message should 

3 0 contain the IP address of the requesting client 

network device so that the legacy network device on 
local network 14 believes it is receiving a message 
directly from the requesting client network device 
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instead of from mimic device 20, If it is 
determined in step S1508 that the outgoing message 
should be transparent to the legacy network device, 
flow passes to step S1509 in which the IP address of 
the requesting client network device is used as the 
source IP address in the outgoing message to the 
legacy network device. In such a case, flow then 
passes to step S1511 in which the outgoing message 
is sent to the NDM which utilizes routing table 74 
to determine that the outgoing message should be 
sent via local network interface card 21 over local 
network 14 to the corresponding legacy network 
device. Flow then passes to return in step S1515. 

If it is determined in step S1508 that it 
is not necessary for the outgoing message to be 
transparent to the legacy network device, then flow 
passes to step S1510 in which the IP address of 
local network interface card 21 is used as the 
source IP address in the outgoing message. As 
mentioned above, local network interface card 21 is 
preferably assigned a pre-registered IP address in 
order to avoid conflicts with any other device, 
either on local network 14 or on external network 
10. It should be noted that even if more than one 
mimic device is present on external network 10, each 
mimic device can use the same preset IP address for 
communicating over its respective local network 
because each local network is isolated from external 
network 10 and therefore IP address conflicts are 
avoided. In this manner, each mimic device does not 
require a separate IP address to be assigned to it 
by the network administrator, thereby saving 
valuable IP addresses for other devices on external 
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network 10. After step S1510, flow then passes to 
step S1511 in which the outgoing message is sent to 
NDM 64 which utilizes routing table 74 and sends the 
outgoing message through local network interface 
5 card 21 over local network 14 to the corresponding 

legacy network device , such as legacy network 
printer 15. Flow then passes to return in step 
S1515. 

If it is determined in step S1507 that the 

10 outgoing message is not directed to the 

corresponding legacy network device, then flow 
passes to step S1512 in which it is determined 
whether the outgoing message is directed to another 
application residing in mimic device 20. For 

15 example, a request from a client network device on 

external network 10, such as workstation 12, may be 
a request for e-mail printing of a secure print job 
on legacy network printer 15. In such a case, the 
print job would require the services of e-mail 

2 0 printing application module 71 and secure printing 

application module 70. Accordingly, e-mail printing 
application module 71 would need to communicate with 
secure printing application module 7 0 to complete 
the decrypted e-mail print job prior to sending it 

2 5 to legacy network printer 15 for printing. 

Accordingly, an outgoing message from one of the 
aforementioned applications would be prepared and 
then handled within mimic device 20 such that it is 
sent back up to the other desired application for 

30 processing. Specifically, if it is determined that 

the outgoing message is directed to another 
application in mimic device 20, then flow passes to 
step S1513 in which the destination IP address of 
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the outgoing message is set to the IP address of 
external network interface card 22 and the source IP 
address of the outgoing message is set to the IP 
address of the requesting client network device* In 
5 this manner, the destination IP address having a 

value corresponding to external network interface 
card 22 informs NDM 64 in conjunction with routing 
table 74 that the outgoing message is to be 
contained within mimic device 20. In addition , the 

10 source IP address in the outgoing message having the 

value of the requesting client network device allows 
the outgoing message to have transparency such that 
the receiving application within mimic device 20 f 
such as e-mail printing application module 71 , will 

15 believe that it received the message directly from 

the requesting client network device. 

After step S1513, flow passes to step S1514 
in which the outgoing message is sent to NDM 64 
which consults routing table 74 and then, based on 

20 the destination IP address in the outgoing message 

having the value of external network interface card 
22, loops the outgoing message back up to NTC 65 
which in turn directs the outgoing message up to the 
desired application, such as e-mail printing 

2 5 application module 71. In this regard, it should be 

further explained that the outgoing message contains 
a port identifier corresponding to the desired 
destination application so that NTC 65 will be able 
to direct the outgoing message to the desired 

30 application in mimic device 20. For example, the 

outgoing message may request the services of e-mail 
printing and therefore it will have a port 
identifier within the outgoing message corresponding 
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to e-mail printing application module 71. 
Accordingly, when the outgoing message is looped 
back from NDM 64 to NTC 65 as discussed above, 
NTC 65 will know that the outgoing message is 
directed to e-mail printing application module 71. 
After step S1514, flow passes to return in step 
S1515. 

Based on the above discussion and 
accompanying figures, it can be appreciated that the 
present invention provides a general, efficient 
manner in which to augment the functional 
capabilities of existing, legacy network devices in 
a transparent fashion. Accordingly, the present 
invention reduces the need for replacing legacy 
network devices, such as network printers, with 
newer versions in order to provide support for new 
enterprise functions. In addition, because the 
mimic device acts on behalf of legacy network 
devices by responding to network messages addressed 
to the legacy network devices, minimal configuration 
effort is required on the part of the system 
administrator . 

It should be appreciated that the mimic 
device described above is not limited to augmenting 
the functional capabilities of legacy network 
printers, but can also be applied to network 
copiers, network scanners, network workstations and 
other network devices. In addition, the above- 
described mimic device is not limited to the 
functional augmentation of network devices, but can 
also be easily configured to perform other 
functions. The rules contained in the rules tables 
described above can easily be configured by the 



applications manager and applications residing in 
the mimic device to allow the mimic device to 
perform a variety of different functions. 

In a particular embodiment, the mimic 
device can be used to provide network connectivity 
to a device which does not inherently have such 
capability. In this embodiment, local network 14 
would be a Universal Serial Bus (USB) network or 
another type of serial network and local network 
interface card 21 would support USB connectivity. 
The rules would then be configured to have mimic 
device 20 act on behalf of network messages from 
external network 10 which are directed to IP 
addresses assigned to the printers on the USB local 
network 14. One of other application modules 72 
would then act as a translator between IP messages 
on external network 10 and USB messages on local 
network 1 4 . 

In a similar fashion, mimic device 2 0 can 
also be used as a docking station which connects to 
a device, such as a digital camera via local network 
14 acting as a USB, or through another serial 
interface in place of local network interface card 
21. For example, a digital camera connects to a 
serial port on mimic device 2 0 which then downloads 
digital images from the digital camera to the mimic 
device and passes the digital images over external 
network 10 to server 11 for storage. Again, this 
simply requires a reconfiguration of the rules 
described above, which can be performed by 
application manager module 78 and/or other 
applications in mimic device 20. 



Mimic device 2 0 can also utilize its two 
independent network interface cards to act as a 
universal networking device. For example, the rules 
can be configured to instruct mimic device 2 0 to act 
as a router , a firewall , a NAT, a server or other 
network device. This is simply a matter of having 
one of the applications in mimic device 20 to 
configure the rules to instruct NTC 65 to perform 
the desired handling of frames detected on external 
network 10 and local network 14. In this regard, 
the rules in mimic device 2 0 can also be configured 
to simply monitor network traffic on one or both of 
external network 10 and local network 14, which 
could include capturing and recording some or all of 
the network traffic. Lastly, the rules of mimic 
device 2 0 can be configured to detect and intercept 
the transmission of undesirable network traffic in a 
defensive mode, or to send undesirable network 
traffic as an offensive, hostile mode. 

The invention has been described with 
particular illustrative embodiments. It is to be 
understood that the invention is not limited to the 
above-described embodiments and that various changes 
and modifications may be made by those of ordinary 
skill in the art without departing from the spirit 
and scope of the invention. 



